10.2 FHIR友好架构的能力要求
搭建企业架构完成数字化转型过程是一项高度复杂的工作，即使在发展水平相对比较成熟的行业如金融、电信等，也经历了数十年的发展演进而不是一朝一夕之功。标准协议的应用过程尽管只是整个企业架构中的一个组成部分，也很难经过一两期建设就达到预期的效果并能自动应对未来的挑战。因此，可以预期医疗机构对FHIR的使用也将经历从简单到深入，从套用到应用的过程，那么在这个过程中的不同阶段，企业可以利用FHIR协议与架构提供的特性、功能与工具来应对这个阶段的挑战。
10.2.1 协议一致性保障能力
协议一致性确保了互操作的双方在多个层面达成的共识不被实际执行所违背。当这项能力存在薄弱环节时，组织产出的标准化实施成果就可能存在各种不一致性和不确定性，使得系统之间互操作的效果也大打折扣，不得不为此付出更多用于补救的后期成本。这项能力的要求通常作用于软件开发生命周期中的多个过程，由多方面的一致性保障来实现。
10.2.1.1 模型一致性保障
模型作用于语法和语义层面，确保信息可以被正确地传递、理解和利用。FHIR的模型包括了资源、资源的元素、元素的值集和术语。
由于FHIR标准对一致性的定义是长期积累所得，组织获取保证模型一致性能力的途径并非“从零开始”，而是可以从FHIR社区的推荐实现入手，以此快速赋能自身。通过从一个已经完善的框架及其提供的约束中，按需学习这项标准，以求平滑实施者的学习曲线。
例如资源的概念和资源的元素等语法一致性方面的要求具备明确的定义，它们大多都是可以被计算机处理的元数据，因而可以通过实现框架或校验工具来参与一致性保证。语义方面的一致性则无法采用这种方式。提供语义互操作仍然是一项“以人为本”的工作，它往往与组织中人员的知识、经验及分析能力紧密相关，并需要多种不同角色的协同和上下游联动提供保障。因此，它同时对技术架构和非技术架构（如组织架构）提出了要求。
10.2.1.2 交互一致性保障
交互是指使用模型发起信息交换的行为，这一行为伴随了预期的场景、角色和时机。这部分预期的信息并不总是存在于所交换的信息中，但却作为这一交互的上下文信息在客观上存在。有时这项能力也被称为语用互操作。管理这些预期并将它们与其它模型一同发布，对互操作项目而言至关重要。
交互是指使用模型发起信息交换的行为，这一行为伴随了预期的场景、角色和时机。这部分预期的信息并不总是存在于所交换的信息中，但却作为这一交互的上下文信息在客观上存在。有时这项能力也被称为语用互操作。管理这些预期并将它们与其它模型一同发布，对互操作项目而言至关重要。
FHIR在资源交换中约定了几种方式，并每一种对资源的操作的业务语义进行了规范。例如通过POST操作创建一个新的Encounter实例，这可以被定义为，因为预约或挂号等活动而开始一次就诊业务，这意味着医疗机构正式地对此业务进行跟踪并付出成本。类似这样的语义可可以明确资源实例开始（或结束）其生命周期时，对业务意味着何种影响。因此互操作流程的设计者可以依赖协议级的语义规范消除业务流程中的歧义，使得流程的定义中不存在对接收方产生不利影响的不确定因素。这类因素是完善业务流程上下文的必要设计项。
10.2.2 互操作辅助实现能力
本节讲述了在互操作设计实战中需要面临的一些经典问题以及解决它们需要具备何种能力。
10.2.2.1 映射与转换能力
大部分的互操作项目设计和实施的具体工作，都与映射和转换这样的工作形式相关。因为互操作本质上要解决的是异构系统协作问题。就好像和自己国内的亲朋好友打电话沟通并没有什么障碍，和国外友人就不同了。
有关映射和转换工作最困难的部分往往出现在结构性不一致上。这种结构上的不一致可以是概念上的，也可以是存在形式上的，或者经常是两者兼有。当面临表面上看来不可调和的分歧时，就需要深入本质、解构细节、挖掘要素、重组逻辑。
10.2.2.1.1 术语映射能力
术语映射能力是最基础的概念映射能力，通常对应于系统双方的数据字典之间的映射。FHIR协议作为一个框架性的标准，不仅仅支持单一的术语来源。实施者可根据国家/团体标准的需要定义特定的profile，绑定特定的术语集来满足国家/团体标准的需要。
10.2.2.1.2 标识映射能力
每一个实体的实例都有其唯一标识，FHIR的资源也是一样。标识的映射本质是实体之间的映射，需要先确定实体存在的内涵与边界，才能为此确定代表其唯一性的标识。在FHIR标准的实施过程中，通常都需要将信息系统中几百甚至更多的表所代表的实体，映射到FHIR中会使用到的大约几十种FHIR资源类型上。集成过程中通常需要在两个系统间通过标识映射记录数据的血缘，提供源-标准数据的双向可跟踪性，通过映射进行数据质量的回溯和数据变更的传递。FHIR提供的Identifier机制能够通过标识映射满足数据双向映射的需求。
10.2.2.1.3 标准映射能力
FHIR标准的使用者并不需要从零开始构建标准化能力。FHIR的每个资源类型页面都带有Mappings页签，提供了其他标准（主要是HL7 V2, V3, CDA）与FHIR之间的映射关系。除此之外，如何具体表述结构之间的映射关系，可以使用StructureMap资源以及FHIR为此定义的映射语言(FHIR Mapping Language)。通过这些可被机器识别的映射工件，开发者可以在现存的标准化基础上搭建出基于FHIR的产品。
10.2.2.2 信息交换支撑能力
10.2.2.2.1 信息模型管理
FHIR资源定义除用于保障信息传输时的语义一致性外，也为建立临床或业务概念的数字化共识创造了条件。对标准化的数据元、元数据、标准数据集等信息模型的发布、更新、退运等管理活动都能受益于FHIR的资源和数据集的标准化，使医疗行业数据能够在系统、机构和区域间自由流通和共享。
10.2.2.2.2 支撑流程编排
在基于信息系统设计方法论进行系统实现的过程中通常不会考虑跨系统业务交互的需求，因此当前的医疗业务流程通常并未规划与第三方系统的协作。现在的业务流程不再局限于单一系统中，跨系统、跨机构的业务流程的需求则很旺盛且变化频繁。FHIR协议提供的包括API、消息、文档、SOAP服务、持久化存储等多种信息交换范式可适应实时、批量等多种交互场景的需要，使基于标准化的数据接口编排数据流程成为可能。
10.2.2.3 数据利用能力
除满足信息交换需求外，FHIR协议也非常重视对数据利用的支持，提供了对批量数据操作和数据检索的规范。例如FHIR协议的查询操作就能支持根据患者的性别、年龄段、诊断、检验检查结果和用药记录等筛选患者。
但FHIR的数据利用规范对信息平台的架构是有要求的，以业界目前针对不同场景提出的参考技术路径为例：
1)FHIR信息交换网关，FHIR协议作为集成引擎采用的标准协议使用。这个模式比较适合集成平台类项目，但FHIR协议定义的批量数据处理、数据检索等能力则较难实现。在没有资源存储库的前提下，很难遵循FHIR来实现对数据的检索并高效地在运行时从HIS、LIS、PACS和发药系统汇聚数据进行响应。
2)包含持久化存储的FHIR服务器，即将FHIR资源库与FHIR协议实现一并投入使用。此时FHIR的批量数据操作和数据检索都可以在FHIR资源库的基础上得以实现，因此不但能够支撑信息交互，也能够被用于进行数据利用。但其实施除了实现信息交换网关的所有功能外，显然也需要参照数据中心的建设过程，实现数据的聚合与清洗，因此实施成本较单纯实现信息交换网关要高。
包含FHIR存储的方案与互联互通成熟度测评考虑的参考架构有共通之处，即在构建集成架构时已经将数据的存储作为一个部件或子系统纳入在架构中并期望基于该存储汇聚离散的医疗数据以支撑更多类型的业务。
10.2.3 生态开放性集成能力
FHIR协议在早期设计阶段就考虑到了将医疗行业数据与AI、BI技术进行整合的可能性。因此FHIR的范围不仅仅包含细粒度的信息交换，也包含与临床决策支持体系或第三方应用的无缝集成。
10.2.3.1 基于CDS-Hooks的临床决策支持能力
详见本书8.4章节
10.2.3.2 支持Smart On FHIR应用开发能力
Smart On FHIR是一个基于FHIR标准和临床数据的可互操作的电子健康记录应用规范。它定义了应用如何获取临床信息以及如何展现信息，应用的开发者因此可以专注于决策逻辑和合规性的研发，从而促进新兴医疗应用在医疗机构的落地。
目前Smart On FHIR已经拥有非常活跃的开发者社区和应用商店，支持FHIR协议及其认证与授权要求的平台可以将应用商店中的Smart应用部署在本地并依照规范进行配置，即可将这些应用集成在工作流程中，极大地降低了应用的落地成本。